home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 938 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.5 KB
  1. Path: fido.asd.sgi.com!austern
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Referencing pointers after delete
  5. Date: 01 Apr 1996 17:03:37 PST
  6. Organization: University of California, Riverside
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4jpseg$fus@galaxy.ucr.edu>
  9. References: <4jmibl$qvt@mulga.cs.mu.OZ.AU> <4jp5dv$lbj@engnews1.Eng.Sun.COM>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 2 Apr 1996 00:30:08 GMT
  12. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMWB86ky4NqrwXLNJAQHXAQH/ZXPZSiVALopbtbFUjrT9uwDYw9vXbS71
  15.     Z7nSF8tAVnFL8qnhH2vOlCqS3Vjr/T/7pZ6K3T3Gg5oUyjNsRHmzTA==
  16.     =jcJw
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. Steve Clamage (clamage@Eng.Sun.COM) wrote:
  20. [...]
  21. : There isn't any way to predict in a platform-independent way what the
  22. : range of responses might be to using an invalid pointer, so the choices
  23.  
  24. The issue is whether one can specify an efficient, reasonable,
  25. platform-independent response.  In general, it depends on the use.
  26. For instance, Accessing the (pseudo)object obtained by dereferencing
  27. an invalid pointer will produce such a range of possibly bizarre
  28. results that there is visibly no way to specify.  But we are
  29. considering the matter of reading a pointer to an deleted
  30. object.
  31.  
  32. : boil down to requiring implementations in general to detect invalid
  33. : pointers at run time, or not requiring them to detect invalid pointers.
  34.  
  35. I know of no acceptably efficient platform-independent mechanism for
  36. detection.
  37.  
  38. : In my view, a requirement like "must raise a signal" as the response is
  39. : no better than requiring any other particular behavior. On some systems
  40.  
  41. So, make the signal optional.  In any case, let processing continue 
  42. with the standard-specified contract between the running program and
  43. the implementation in force at least until something serious happens,
  44. like a derefercing of the invalid pointer.
  45.  
  46. : raising a signal is the default hardware response and comes for free.
  47. : Other systems have no hardware detection or a different hardware
  48.                                            ^^^^^^^^^^^^^^^^^^^^^^^^
  49. : response, so run-time checks would be required to avoid unpredictable or
  50.   ^^^^^^^^
  51. This is probably the hub of our difference: I have difficulty
  52. imagining a reasonable architecture that does something other than
  53. ignoring or trapping the reading of invalid pointers.  (Granted,
  54. "reasonable" is in the eye of the beholder.)
  55.  
  56. : disallowed behavior. Loosening the requirement to "must raise a signal,
  57. : or do A or do B or do C" doesn't change the general case. What if some
  58. : platform, such as a system to be built years from now, normally reacts
  59. : by doing D?
  60.  
  61. There is no way of knowing how some furture architecture might respond
  62. to any operation, not jut that of the reading of invalid pointers.
  63.  
  64. The argument that we need to open up all possible options in response
  65. to the detection of an invalid value misses the point that a signal
  66. handler, invoked upon detection of such a value, can generate whatever
  67. behavior the programmer pleases including a call to abort.  (Note that
  68. this puts the programmer, not the implementor in control of that
  69. response, which is as things should be IMHO.)
  70.  
  71. The real problem, inherited from C, is that in the standard specifies
  72. "undefined behavior" whenever an operation on a valid object might
  73. yield an indeterminate or invalid value, e.g., reading a pointer
  74. object to a deleted object or reading a global variable from a signal
  75. handler.  The contract between the running program and the underlying
  76. implementation is voided even if the program never uses that value.
  77. The common rationale is that such a value can never be put to good use
  78. (e.g., dereferencing the invalid pointer value will yield undefined
  79. behavior anyway), but one might, for instance, cast an invalid pointer
  80. to an integer and print it out for diagnostic purposes.  (In the case
  81. of signal handlers, one can implement locks and signal blocking on the
  82. basis of those indeterminate values.  How else do we handle such
  83. things in assembly language?)
  84.  
  85. I would like the standard to specify that control stays with the
  86. programmer, whenever it is reasonable to do so.  When the standard
  87. says "undefined behavior" such control is lost.
  88.  
  89. Tom Payne (thp@cs.ucr.edu)
  90. ---
  91. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  92.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  93.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  94.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  95.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  96. ]
  97.